home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 11⁄24⁄89 / 0124-Databases and Docume-Nov89 < prev    next >
Encoding:
Text File  |  1989-11-24  |  1.6 KB  |  39 lines  |  [TEXT/GEOL]
  1. Item    7159526                         24-Nov-89        10:53
  2.  
  3. From:   D1165                           Esha, David C Hands,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    Databases and Documents
  8.  
  9. Hello MacApper's,
  10.  
  11. I need some advice on a design issue...  I'm writing an application that can
  12. create two different types of documents.  One type is a database document the
  13. other is a document that is built by retrieving elements of the database (a
  14. rough analogy might be a spelling checker that uses a dictionary database to
  15. create a text document.  Most of the time the user creates text documents but
  16. occasionally they will create a new dictionary document for special words).
  17.  
  18. The question I have is how to organize the two documents types so that an open
  19. "text" document can search and retrieve data from all open database documents.
  20. I don't see a clean way for MacApp to have one document interrogate a second.
  21.  
  22. Also, where and how should a document reference a database.  I can't have a
  23. field of a document be the only reference to the database(s) because I still
  24. need to create/edit databases without creating a document.  The database is
  25. such an integral part of the application (the progran cannot run unless at
  26. least one database document is opened) should it be a field of the application?
  27.  
  28. Any suggestion?
  29.  
  30. David Hands
  31. ESHA Research
  32.  
  33. p.s. I read the article about databases in the September Frameworks and it's a
  34. bit too much for my purposes.  The database I'm searching is a simple flat file
  35. of records, very few database frills are required.
  36.  
  37.  
  38.  
  39.